Conversation
I ended up with a workspace that has two build resources that have the same agent. We ended up creating two environments with the same id (workspace name + agent name) This caused issues in Toolbox.
There was a problem hiding this comment.
I am probably missing something but it looks like this is doing the same thing it already was, just slightly reorganized? The distinctBy looks like it should have already been preventing duplicate agent names.
Or if this is just to add tests, then looks good to me!
But, why not keep it as a set, does a set not actually guarantee uniqueness?
Edit: forgot to say, I see we removed the TODO, do we know now that we can just choose any agent arbitrarily or if it matters which one we pick? Even though the name is the same, other details about the duplicates might be different (status, ID, etc) so I am not sure we can just pick one at random.
|
Good points, I was planning to slowly refactor and improve this block for a couple of reasons:
TLDR; this is an attempt to fix a regression while at the same time to improve the readability and make some things obvious. I can just convert everything to sets and the fix would be much clear. |
|
Ahhhh I see the distinct by is applied to the merge of all the workspace's resources now, rather than applied to each individual set of resources. Makes sense! |
I ended up with a workspace that has two build resources that have the same agent. We ended up creating two environments with the same id (workspace name + agent name) This caused issues in Toolbox.